Agent上下文压缩与记忆策略：5种压缩、3类记忆形态及4条选型红线，兼看MemGPT、ACON与Context Editing

今天来看看 Agent 常见的上下文压缩策略以及记忆策略。上下文工程 Context Engineering 是个有趣的话题，"上下文为什么会爆炸?"，方案那么多，到底怎么选。今天这篇就是来还这个账的。

最近读了两份一手材料：一份是 47 位作者合写的综述《Memory in the Age of AI Agents》（arXiv:2512.13564），一份是 ICML 2026 的《ACON: Optimizing Context Compression for Long-horizon LLM Agents》（arXiv:2510.00615）。前者把"记忆"这个词从长/短期的粗糙二分里拽出来，重切成 forms、functions、dynamics 三个轴；后者给出了一个很工程化的信号——压缩准则本身可以在自然语言空间里被优化，完全不需要动模型权重。

一、压缩不是记忆，记忆也不是 RAG

先说一个误区。现在大量团队在聊"Agent 记忆"，但聊的其实是三件完全不同的事，全都塞在同一个词里：

如图1。这个三分法不是我拍的，arXiv:2512.13564 那篇综述开篇就在做同一件事——它明确把 agent memory 与 LLM 参数记忆、RAG、context engineering 三者切开，理由是"loosely defined memory terminologies 已经把概念清晰度毁掉了"（原文）。

核心点出来了：压缩作用在窗口内部，记忆作用在窗口与持久层之间。这两件事的接口顺序是不能反的——先落盘，再压缩。Anthropic 把 context editing 和 memory tool 设计成必须配对使用的功能，就是这个道理：context editing 负责把上下文变小，memory tool 负责把被擦掉的东西留一条后路。

很多团队买了一个"记忆系统"之后，做的第一件事是把历史对话全量塞进去，然后每次提问 recall top-k。这其实是 RAG，不是记忆。真正的记忆要能回答"上周我们为什么放弃了方案 B"，而不是"方案 B 的文档里写了什么"。

二、为什么必须压缩：三个硬约束，一个都不是玄学

先说结论：压缩不是"省钱技巧"，它是长程 Agent 能不能跑完任务的前提条件。约束来自三个方向，且互相独立。

约束一：注意力预算（attention budget）。 Anthropic 在《Effective context engineering for AI agents》里给了一个很好用的说法——context 是一种有限资源，且边际收益递减。transformer 里每个 token 都要和其余所有 token 建立关系，n 个 token 就是 n² 组关系；窗口越长，模型捕捉这些两两关系的能力被摊得越薄。加上训练数据里短序列远多于长序列，模型对"跨整个窗口的长程依赖"本来就没练够。

约束二：context rot 与 lost in the middle。 针尖麦芒式基准测试早就发现，随着窗口内 token 数上升，模型准确回忆信息的能力是下降的——这就是 Anthropic 说的 context rot，也是 Liu 等人 2023 年那篇《Lost in the Middle》（arXiv:2307.03172）给出的 U 形曲线：信息放在开头和结尾好找，放在中间就失踪。这一点尤其要注意，因为它意味着"上下文变长"不是免费的，它同时在降低质量和提高成本。

约束三：KV cache 与推理显存。 ACON 那篇把这个说得最直白：transformer 的推理显存随上下文长度增长，长程 agentic 任务里的 KV cache 需求大到让推理变得不可行。这一点在做私有化部署、尤其是小模型上 Agent 的时候最要命——窗口还没满，卡先满了。

❝所以压缩的目标从来不是"塞更多东西进去"，而是 找到最小的高信号 token 集合。这句话是 Anthropic 原话的转述，也是本文的技术主线。

三、5 种上下文压缩策略：从无损到有损

先说结论：压缩策略要分层用，顺序不能乱。无损的结构性裁剪先做满，有损的语义重写最后做。跳过 L1 直接上 L3，是大多数"省钱省到任务失败"的根源。

1、Just-in-time 加载：不预塞，按需取

这是四个模式里唯一的"设计模式"，不是 API 能力——没有任何平台会替你做，它纯粹是你决定什么时候加载什么。合规审查 Agent 不该把整本建筑规范塞进 system prompt，而应该在需要某一节时调用 lookup_building_code。

优点：零成本、零损失。缺点：要求你把 tool 设计得足够正交，否则 Agent 会为了拿一条信息连打五个工具（这个很常见，也很贵）。

2、工具结果清除 tool result clearing：最轻、最安全的一刀

这个是 ROI 最高的一招，也是最少人用的一招。 一条 tool_result 在被消费之后，Agent 为什么还要再看一遍原始 JSON？

Anthropic 把这件事做成了服务端能力 context editing：在请求里挂 context_management={"edits": [{"type": "clear_tool_uses_20250919"}]}，配 beta context-management-2025-06-27，服务端会在上下文接近阈值时自动擦除旧的 tool_use / tool_result，并在擦除前给模型一个"该存记忆了"的提示。

response = client.beta.messages.create(

model="claude-opus-5",

messages=[{"role": "user", "content": "..."}],

tools=[{"type": "memory_20250818", "name": "memory"}],

betas=["context-management-2025-06-27"],

context_management={"edits": [{"type": "clear_tool_uses_20250919"}]},

)

Anthropic 随功能发布给出的数据：在 100 轮 web search 评测里，单做 context editing 就把 token 消耗降了 84%；在 agentic search 任务上，context editing 单独带来 29% 提升，与 memory tool 组合则到 39%。

局限要写清楚：它只对"已经消费过的工具结果"安全。如果你的 Agent 有回头引用三小时前某次工具返回值的习惯（不少代码 Agent 就有），清除之后会出现"引用了不存在的 tool_use_id"这类硬错误。所以清除策略要配"结果引用计数"或者干脆只清 N 轮之前的。

3、sub-agent 隔离：把探索的代价关在门后

子代理架构是另一种绕开上下文限制的办法：主 Agent 只持有高层计划，专门的子代理各自用干净的上下文深挖，最后只回传 1,000–2,000 token 的浓缩摘要。Anthropic 的多 Agent research system 就在用这个模式，且在复杂研究任务上显著优于单 Agent。

这个可以借鉴的地方在于关注点分离：搜索过程消耗的几万 token 被隔离在子代理内部，主 Agent 的上下文里只剩结论。风险是误差传播——子代理摘要时丢掉的那条限定条件，主 Agent 永远看不到，也无从追问。所以子代理回传的摘要必须强制带来源引用（文件路径 / URL / 工具调用 ID），否则没法回溯。

4、token 级剪枝：LLMLingua / LongLLMLingua

这一类走的是另一条路：不动语义，直接在 token 层面删。LLMLingua（arXiv:2310.05736）用一个小模型算困惑度，把"可被预测的 token"删掉，并采用迭代式删除 + 预算分配；LongLLMLingua（arXiv:2310.06839）再加了两件事——question-aware 的粗到细压缩，以及文档重排来对抗位置偏置。

数字很漂亮：NaturalQuestions 上用约 1/4 的 token 还涨了 21.4%；LooGLE 上成本降 94%；10k token 的提示在 2x–6x 压缩比下端到端延迟快 1.4x–2.6x。

但这一类方法对 Agent 轨迹是高危的。 它的底层假设是"令人意外的 token 才是信息量高的 token"——这个假设对自然语言叙述成立，对 /src/api/v2/handler.py:142 这种字符串基本不成立：路径分隔符、版本号、行号都是高可预测 token，一删全废。所以我不建议把 LLMLingua 单独用在 Agent 的 action/observation 轨迹上；用在"喂给 Agent 的文档语料"上是合适的，那才是它的甜点区。

5、语义重写 / compaction：最后手段，但不可避免

递归摘要是最常见的基线：

messages = conversation_history

while token_count(messages) > limit:

oldest_chunk = messages[:chunk_size]

summary = LLM.summarize(oldest_chunk)

messages = [summary] + messages[chunk_size:]

生产环境里就是 Anthropic 的 server-side compaction（请求里挂 {"type": "compact_20260112"}，配 beta compact-2026-01-12，服务端在输入越过阈值时自动摘要）和 Claude Code 的 auto-compact（默认在接近窗口上限、约 95% 时触发）。

失败模式非常稳定：压缩发生在模型还不知道用户接下来会问什么的时候（这个最小幻觉原则的反面），而且具体细节——人名、数字、文件路径、API 参数——在多轮摘要之后存活率极低。

ACON（arXiv:2510.00615，ICML 2026）针对的就是这一点，而且思路很巧：它不微调模型，而是把"压缩准则"当成被优化对象。做法是跑一批训练任务，找出"用全上下文成功、用压缩上下文失败"的对比轨迹，让一个 optimizer LLM 分析到底丢了什么状态，用自然语言反馈迭代改写压缩 prompt；分两阶段（先 Utility Maximization 保成功率，再 Compression Maximization 压长度），最后把优化好的压缩器蒸馏到小模型。

结果：AppWorld / OfficeBench / Multi-objective QA 上峰值 token 降 26% ~ 54%，成功率不降反升；小模型（Qwen-14B）作为长程 Agent 时提升最高 46%，因为它被"上下文干扰"拖累得最狠。

这个思路可以借鉴：压缩准则不该是手写的一次性 prompt，而应该是可以被评测数据反复打磨的产物。局限是——它需要"成功/失败轨迹对"作为燃料，冷启动时没有数据，仍然得从手写准则起步。

五种策略横向对照

四、3 类记忆形态：别再用"长期/短期"糊弄自己

arXiv:2512.13564 提出用三个轴同时描述一个记忆系统，比"长期/短期"这种从认知科学借来的二分好用得多。

Forms：存在哪儿？什么形态？

token-level：明文文本，在上下文里或在外部库里。可读、可编辑、可 diff、可审计。MemGPT 的 core memory、Claude 的 memory tool（/memories 目录下的 md 文件）、Claude Code 的 CLAUDE.md 都是这一类。parametric：写进权重或 adapter。快，但改不动、删不掉、还可能灾难性遗忘。latent：隐状态 / 向量 / KV。压缩率高，不可读，不可审计。可审计性排序是 token > latent > parametric。这一点在企业场景里是硬约束——出了事你要能回答"Agent 为什么这么决策"，参数级记忆答不了这个问题。

Functions：记忆是干什么的（替代长段时）

factual 事实记忆：用户是谁、项目约定、领域知识。experiential 经验记忆：上次踩的坑、哪种解法在这个库里有效、反思结论。working 工作记忆：当前目标、进度、计划、待办。诚实的一句话：市面上的产品大多只做了 factual，experiential 基本空缺。而 experiential 才是记忆真正的价值所在——"能捞回来"和"能改变下一次行为"是两回事，后者才是记忆，前者只是检索。

Dynamics：怎么流转

formation（形成：知识抽取）→ evolution（演进：巩固、冲突消解、遗忘）→ retrieval（检索）。

多数生产系统只做了 formation，而且是 append-only 日志。半年之后，一个"用户偏好"存了 40 条互相矛盾的记录，检索回来自己也分不清哪个新。没有遗忘机制的记忆系统，跑过三个月就是噪音源——这一点尤其要注意。

代表系统对照

关于 Mem0 的数字要说一句公道话：论文报告的"26% LLM-as-a-Judge 相对提升、91% p95 延迟下降、90%+ token 成本节省"，基线是"把整段对话全塞进上下文"。真实生产系统几乎不会这么干，所以对照一个已经做过压缩的系统，收益会小得多。而且论文没有把抽取链路本身的成本算进去——每一次写入要调 1–2 次 LLM，100 轮对话就是 100–200 次额外调用，这部分是纯增量。

五、压缩与记忆的接口：这是本文真正想讲的地方

前面四节拆完之后，接口其实只剩一句话：压缩负责让窗口变小，记忆负责让被压缩掉的东西还能回来。两者必须同开，且记忆的写入必须先于压缩的执行。

Anthropic 的实现把这件事说得很明白——context editing 在上下文接近清除阈值时会主动给模型一个警告，提示"该把重要信息存进记忆文件了"；memory tool 则是客户端实现的文件系统（view / create / str_replace / insert / delete / rename 六个命令，作用在虚拟 /memories 目录上）。存储后端你自己选：本地磁盘、数据库、加密 blob 都行。

这个设计有个很有意思的细节：系统提示会被自动注入一句 ASSUME INTERRUPTION: Your context window might be reset at any moment，逼模型养成"边干边记"的习惯。加上官方建议的三件套——progress log + feature checklist + 启动脚本引用——本质上是把一个"记忆目录"变成结构化的恢复机制，让每个新 session 能精确接上上一个 session 断掉的地方。

实践里我自己会加两条约束：

结构化笔记必须分栏。 目标 / 已完成 / 关键发现 / 未决问题 / 状态类常量。分栏的作用是防止"渐进式信息丢失"——每一栏都是一张 checklist，写的时候就会发现自己漏了什么。状态类常量单独成文件，且永不压缩。 文件路径、资源 ID、API 参数、约束条件、待办清单。这些东西不进摘要链路，原样保留。安全上也要提一句：memory tool 允许模型构造任意路径，官方文档明确要求实现方 MUST validate all paths 防止目录穿越，拒绝 ../ 及其 URL 编码变体，并校验规范化路径仍在 /memories 内。这条容易被忽略，但它是真实漏洞面。

六、4 条选型红线 + 1 条评测标尺

红线一：状态类信息禁止走有损压缩

路径、ID、API 参数、版本号、约束条件、待办状态——这些必须在压缩前 flush 到持久层，或者干脆常驻不压。理由前面说过：token 级剪枝会按"可预测性"删掉它们，摘要会在多轮后磨掉它们，而丢一条文件路径就能让整条工作流前功尽弃。

红线二：先算规模，再决定要不要上记忆系统

大多数团队根本不需要记忆系统。 判断标尺：峰值上下文 < 50k token 且轮次 < 20 的场景，Just-in-time 加载 + 工具结果清除 + prompt caching 就足够了，上一个 Mem0 或图数据库是纯负收益——多了抽取链路的钱、多了运维的活、多了一层不确定性。

红线三：压缩阈值别顶到窗口上限，留 20–30% 余量

Claude Code 默认在约 95% 触发 auto-compact，这个数对"最后一搏"是合理的，但对生产系统偏冒险：摘要请求本身要吃 token，如果余量不够，可能在你最需要完整历史的时候反而拿不到。建议服务端 compaction 之外自己再加一层更保守的阈值，并且在压缩前强制 flush 一次记忆。

红线四：记忆必须有演化与遗忘，append-only 日志不是记忆

要么做冲突消解（Mem0 的 update resolver、Zep 的 bi-temporal 失效边），要么做定期归并（把 40 条用户偏好合并成 1 条带时间戳的结论）。什么都不做的话，三个月后你的记忆库就是个噪音放大器。

评测标尺：别只测 recall

现在主流的记忆基准（LoCoMo arXiv:2402.17753、LongMemEval arXiv:2410.10813）大多测的是"能不能回忆起对话里出现过的某个事实"。但真正该测的是三件事：

任务成功率随轮次的衰减曲线——第 5 轮和第 50 轮的差距有多大；token 峰值与总成本（含抽取链路的调用成本，别只算检索侧）；记忆库随时间的信噪比——跑三个月之后，检索回来的 top-5 里还有几条是有用的。第三点几乎没有 benchmark 覆盖，但它决定了一个记忆系统能不能活过半年。

七、总结

本文主要介绍了 Agent 常见的上下文压缩策略（Just-in-time 加载、工具结果清除、sub-agent 隔离、token 级剪枝、语义重写 compaction）以及记忆策略（forms / functions / dynamics 三个轴，MemGPT、A-MEM、Mem0、Zep、MemoryOS 等代表系统），重点看了两者之间的接口顺序。

一句话提炼：压缩是窗口内的有损重写，记忆是跨窗口的可回捞外置；先落盘、再压缩，没有被持久化的信息不配被压缩掉。 这个判断对 RAG 也一样成立——先分清"Agent 自己的经历"和"外部文档知识"，再决定它们各自该走哪条链路。

启发1：不要因为"我们有长上下文了"就放弃压缩，context rot 是架构级的约束，不是工程没做好；启发2：也不要因为"我们有记忆系统了"就放弃压缩，记忆解决的是跨 session，压缩解决的是单 session 内的注意力预算，两者不互相替代。关于我们

老贾探AI团队，专注企业级 RAG 知识库 / Agent 智能体 / 本体论技术拆解，定期发布相关方向的深度解读与冷思考，欢迎关注。

对 KG、RAG/GRAG/OAG、Agent、Ontology 落地感兴趣，欢迎后台私信-加入社区交流。

参考文献

1、Memory in the Age of AI Agents（forms / functions / dynamics 三分法，47 位作者综述）：https://arxiv.org/abs/2512.13564

2、ACON: Optimizing Context Compression for Long-horizon LLM Agents（ICML 2026，自然语言空间的压缩准则优化）：https://arxiv.org/abs/2510.00615 ，代码：https://github.com/microsoft/acon

3、MemGPT: Towards LLMs as Operating Systems（虚拟上下文管理，现为 Letta）：https://arxiv.org/abs/2310.08560

4、A-MEM: Agentic Memory for LLM Agents（NeurIPS 2025，Zettelkasten 式记忆演化）：https://arxiv.org/abs/2502.12110

5、Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory：https://arxiv.org/abs/2504.19413

6、Zep: A Temporal Knowledge Graph Architecture for Agent Memory：https://arxiv.org/abs/2501.13956

7、LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression：https://arxiv.org/abs/2310.06839 ；LLMLingua：https://arxiv.org/abs/2310.05736

8、Lost in the Middle: How Language Models Use Long Contexts：https://arxiv.org/abs/2307.03172

9、Generative Agents: Interactive Simulacra of Human Behavior（memory stream + reflection）：https://arxiv.org/abs/2304.03442

10、Anthropic，Effective context engineering for AI agents（context rot、attention budget、compaction / 结构化笔记 / sub-agent）：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

11、Claude Platform 文档，Context editing（服务端清除 + compaction 参数与 beta header）：https://platform.claude.com/docs/en/build-with-claude/context-editing

12、LoCoMo: Evaluating Very Long-Term Conversational Memory of LLM Agents：https://arxiv.org/abs/2402.17753 ；LongMemEval：https://arxiv.org/abs/2410.10813

13、MemoryOS（热/温/冷分层记忆，EMNLP 2025 Oral）：https://arxiv.org/abs/2506.06326